1. Field of the Invention
The present invention is in the field of work and data sharing, and pertains particularly to federation between business enterprises.
2. Discussion of the State of the Art
At the time of the present patent application federation is becoming more common in certain business communications, such as instant messaging. Federation allows members of more than one enterprise to share information with one another, usually to a limited extent, and often, as in the case of instant messaging, to monitor contact presence across enterprise boundaries.
Typically, federated systems are set up explicitly, and are limited in scope. For example, members of various enterprises who may jointly participate in a relatively complex project may wish to share information about the project with one another using some common communications program, such as Microsoft Office Communicator. In such a federated project specific members of each enterprise may grant one another permission to “see” each other (presence), and they may agree on who gets to share what information, for example certain members may be limited to information from a designated shared folder.
It is not common in federation at the time of this application that such relationships may enjoy any sort of transitivity. That is, if one member grants another permission to monitor her presence, she is not granting permission for others to monitor her presence, and in fact the software will not permit it. Each person, or an administrator acting on behalf of a group of people within the administrator's enterprise, explicitly establishes each one-to-one sharing relationship.
Such control is crucial in normal business communications, and is also quite common in consumer communications, since privileges granted to a particular person are in general not assumed to be transferable. In fact, one can generally say that in the art, federated enterprise architectures are tightly controlled for sharing specific data or functionality according to specific rules among a group of predefined contacts in member enterprises. Generally there is either a centralized federation server that stores a single centralized configuration database for all federated aspects (in the case of process integration across enterprise boundaries), or a set of local rules for establishing specific access rights of individuals or groups in each enterprise for a specific function (in the case of, for example, instant messaging or collaboration federation).
The present inventors are aware of circumstances where something much more robust than the known architecture of federation is needed. For example, in customer service, such as in contact center situations, it is now common for large enterprises to outsource some or all of their simpler customer contacts while retaining control of more complex contacts. Furthermore, it is often the case that a contact that starts with a customer or client in one enterprise might require transfer to a second enterprise or even a third enterprise before the customer's needs are met.
As an example of unmet need in the art, in many cases mobile phone insurance is provided by specialized insurance providers on behalf of mobile carriers. When a consumer has lost a mobile phone, they often have a single number to call, which is printed on their bill. When they call that number, they are likely to be speaking to a customer service representative (CSR) from the insurance company, even though the CSR may answer the phone as if he worked for the mobile phone company. The insurance CSR can handle the lost phone report, can verify if the phone has been used since its last known use by its proper owner, and arrange for shipment of a new phone (and collection of any charges due for these services). But the insurance company CSR is unlikely to be able to be able to answer questions about changing the mobile phone contract, which need might commonly arise in such a situation. In this case, the call would need to be transferred to a CSR who works for the mobile phone company. Quite often consumers in such situations are simply given a new number to call, or they are cold transferred to the phone company's contact center with no attached data indicating what has taken place between the consumer and the insurance company CSR. In this well-known case, the consumer finds herself repeating much of what was said before.
The previous example gets even more complex when outsourcers are factored in. It may well be that the phone company sends calls transferred from the insurance company to an outsourced contact center over which it has little control. Moreover, as the outsourcing industry matures in countries like India, it is more common for outsourcers to themselves outsource some portion of their own traffic to yet smaller outsourcers. Larger outsourcers in principle centers such as Bangalore or Mumbai enjoy strong relationships with their client base, but suffer from increased labor costs as the rapid development of their home regions causes skilled labor shortages and wage increases. Such large outsourcers are tapping into emerging outsourcing hubs such as university towns like Pune, or other English-speaking countries such as Mauritius.
So, it is clear that there do exist, primarily in the business world, quite complex inter-relationships between enterprises, and in these relationships it is quite common for there to be clumsy and difficult communications between the enterprises involved and customers or clients of those enterprises. What is needed is a federation customer service architecture that does not require explicit, point-to-point links to be configured in advance, and that allows a robust transitivity model to emerge. Further, when the new federated architecture is implemented, federations will become much larger and more complicated, and new and novel control over communications will be needed.